Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/inet/internet-drafts/draft-levinson-sgml-00.txt

Text File | 1993-10-19 | 31KB | 741 lines

Network Working Group                    E. Levinson
Internet Draft: MIME/SGML      Accurate Information Systems, Inc
<draft-levinson-sgml-00.txt>                   October 19, 1993
                                                 Expire: April 1993
MIME Content-types for SGML Documents

This draft document is being circulated for comment.  Please send
your comments to the authors or to the ietf-822 maillist <ietf-
[e-mail]>.  If consensus is reached this document
may be submitted to the RFC editor as a Proposed Standard protocol
specification for use with MIME.

Status of this Memo

   This document is an Internet Draft; Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF) its
   Areas, and Working Groups.  Note that other groups may also
   distribute working documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six
   months.  They may be updated, replaced, or obseoleted by other
   documents at any time.  It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as a
   Rworking draftS or  Rwork in progressS.

   Please check the abstract listing in each Internet Draft
   directory for the current status of this or any other Internet
   Draft.

Abstract

   This document specifies how a specific compound object, a complete
   SGML document, is to be carried within a MIME message. MIME
   provides a flexible mechanism for structuring RFC 822 message
   bodies.  To use that mechanism for compound documents requires
   additional agreements on how the compound document is
   represented and labelled within the message body.  In addition,
   this document specifies the requirements for using MIME to carry SGML
   documents within a data stream in conformance with the SGML
   Document Interchange Format (SDIF).  That format provides a mechanism
   for transferring one or more SGML documents.  Subtypes are
   proposed for the Multipart and Application content types to
   support SGML documents and SDIF within MIME.

   Compound documents, including SGML, consist of a number of
   files, some of which may contain references to other files.
   Explicit indications of the bindings between the sender's file
   names and the MIME body parts are needed to re-bind the sender's
   file names to ones on the recipient's system.  A content
   reference header field makes the bindings explicit.

1    Introduction

Many MIME [RFC-MIME] based mail User Agents can be readily
configured to display (and compose) standard message body content
types.  These user agents  invoke applications that correspond to
the particular content type.  Standard content types exist for
data that consists of a single body part and there are mechanisms
to convey multiple body parts.  However there is no standard
mechanism for objects like compound documents that contain
multiple, inter-related body parts.

Compound documents are represented in various mark-up languages,
e.g. troff, text/enriched.   This document provides a mechanism for
embedding, inside an Internet mail [RFC-822, RFC-MIME] message,
complete documents of one such markup language, the Standard
Generalized Markup Language (SGML) [ISO-SGML].

1.1 SGML

SGML is used in several communities to encode document structure
and layout.  A rigorous description of SGML is left to [ISO-SGML];
Appendix A contains an unbelievably brief description of the SGML
elements relevant to this document.   In this document attempts to be
consistent with SGML terminology and usage.  A complete SGML
document consists of an SGML declaration, a document type
definition (DTD), and a document instance.  The document instance
may, recursively, contain subdocuments which consist of DTDs and
an instance.  The applications that process SGML documents may
require the document parts to be individual files or combined in a
single file.

For a person or application (a recipient) to receive and display a
complete SGML document  a precise definition for each of the SGML
document parts must be carried within the mail message.  In the
sender's environment these parts may be references to standard
parts or specific files in the sender's file system.  Further, a
DTD may reference other files, for example, images and graphics.
The identity of the document parts as well as the name and
contents of each file must be transferred.  Sufficient information
must be accompany the data for the recipient to transform the
sender's file name into an equivalent local reference.

1.2 SDIF

The SGML Document Interchange Format, SDIF, [ISO-SDIF] specifies
the structure for a data stream whcih contains one or more SGML
documents.  SDIF is focused on transferring documents between
sites and does not include a requirement that the documents be
displayed as they are encountered.  Users of mail based systems,
however,  expect to have each mail item in a multipart message
displayed -- more precisely, ready for display -- when
encouneterd.  This document shows how to meet both the SDIF and display
requirements.

1.3 Organization of this Memorandum

First a body part content type for a simple SGML document is
defined.  The discussion of that content type expains the SGML
specific parameters and explores a number of the issues that arise
when transferring an SGML document from one system to another.
More complex documents are handled via a Multipart subtype.
Discussion of that subtype explores additional document transfer
issues.  The discussion concludes by presenting the content types
required to create an SDIF conformant data stream.

2    Processing Model for MIME/SGML

Four issues must be addressed for the recipientUs user agent to
display a complete SGML document: the various parts must be
specified and file and command references on the sender's systems
must be resolved to references on the receiverUs system.  Finally,
an appropriate application, an unpacker, must be in control to
unpack of the MIME body parts containing the document and present
them to the display software.  The controlling application is
discussed first and then the document parts, file references, and
command references.

2.1 Invoking the  SGML Parser Application

MIME offers the possibility to add SGML capability to existing
mail user agents.  To accomplish this with existing SGML viewers
and composers a process must be interposed between the SGML
application and the user agent to translate from MIME format to a
form acceptable to the local SGML application.  This document uses the
notation in [ISO-SDIF] where the process creating the data stream
(here, the MIME message) is called the packer; the correponding
one for  the receiver, the unpacker.

Normally one expects a MIME capable user-agent to display each
body part in turn, usually in a depth first manner.  For a
compound document the display must be deferred until all the body
parts are available to the application and are structured
according to the requirements of the SGML application.  For example,
some SGML viewers expect the DTD and instance be combined in a single
file, others expect them to be separate.  "Available" means that the
files corresponding to the various document parts have been
instantiated on the receiver's system.  Once instantiated, an SGML
viewer can be invoked.  Similarly, an SGML composer will create
the respective parts using its own file structure.  For example,
an SGML application may expect the DTD and document instance to be
in a single file.  The unpacker separates these parts and
encapsulates as separate MIME body parts.

2.2 Specifying the Document Parts

Different implementations of SGML parsers use different  methods
for storing the SGML declaration, DTD, and document instance.
Consequently the unpacker may find these parts as separate body
parts or as a single part and must store them as the local
application requires.  There are several ways to specify each part
of a complete SGML document.  The declaration part may be a
default value and not included, an file which is included, or it
may be part of the document instance.  It could also be a file
each correspondent already has.

An easy solution would be to require a standard form, perhaps a
single file, a concatenation of the declaration, DTD, and
instance.  That would often require the transferring much more
data than needed, often only the document intsance is required.
The discussion so far assumes that there is only one file (or its
equivalent).  While there may be many files, for SGML document
instances as opposed to files of image (or other) data, the
consideration here is only how to specify the document or sub-
document SGML elements.  The next section considers other data .

Rather than require a standard form, this document permits the SGML
document parts to specified as parameters.  Thus a sender may
choose to send the declaration, DTD, and instance as a single file
or may choose to specify any of them as a parameter.  If neither
the SGML declaration nor document type declaration is specified it
may be in the message body; if it is not there then the recipient
is free to apply a local default.

These parameters are provided for each document or subdocument
instance.

    sgml-parm    :=    *( ";" sgml-part "=" sgml-part-spec)
             [ ";" "version" "=" iso-sgml-spec ]
             [ ";" "created-with" "=" ref-or-tok ]
             [ ";" "character-set" "=" charset ]

    sgml-part    :=    "instance" / "declaration"
            /    "dtd" / "fosi" / extension-token

    sgml-part-spec    :=    file-token / sgml-public / extension-token

    sgml-public    :=    <An SGML PUBLIC identifier>

    iso-sgml-spec    :=    <The identifier of the SGML specification
                to which the document conforms, e.g. ISO
                8879-1986>

Sgml-parts specify the various parts of a complete document.  File-
tokens are discussed in the next section.  If used that file's
contents will be contained in a body part and will be labelled
with a content-reference: field.  Sgml-public are identifiers
defined in [ISO SGML] which represent well known files or
entities.  The SGML parser is expected to resolve these references
on its own.  Although  the SGML definition provides for
associating location (local file system) information with public
data this document does not supported it.  It is possible to provide
support for that capability in the unpacker.

The two parameters, version and created-with, are provided for
guidance to user agents.  Version specifies the particular SGML
standard to which the document conforms.  A user agent can use
this value to invoke the application appropriate to that version
of the standard.  The created-with parameter provides guidance in
cases where inter-operability with respect to SGML may be a
problem.  In those environments, where user's maintain several of
SGML processors, this parameter can be used to invoke the
appropriate implementation.

The character-set parameter specifies the body part character
set.  If not specified, the default is us-ascii.

2.3 Resolving File References

SGML permits the DTD to define document parts (entities) that a
document instance can reference for inclusion or interpolation.
The entities point to files that can contain SGML coded text, text
not to be interpreted, images, or other data.  Within SGML there
are two types of file reference entitites SYSTEM and PUBLIC.
PUBLIC entities specify SGML document parts that are known to and
resolvable by SGML viewers and editors.  The SYSTEM identifiers
refer to files in the local environment.  In order for the
recipient's SGML application to properly process the document, the
file references must be resolvable in the recipient's environment.
Conceptually, one must replace each of the sender's file
references with a corresponding reference in the recipient's file
system.

There are two issues here.  First, the sending user agent must
parse the document and identity the sender's file references.
Second, the internally referenced file will become a MIME body
part and the correspondence between the file name and the body
part must be preserved.  This document applies the principle of "sender
makes right" to these issues and requires first, that the packer
converts all file references into a unique token containing only
US-ASCII characters.  Second, those files will be a body part in a
multipart MIME message and the corresponding body part header must
contain a Content-Reference: field whose value contains the file's
token.  Thus, the internal file name, now a token which can appear
in an 822 header, explicitly appears in the document and its
corresponding MIME body part using the Content-Reference: field.
When the unpacker stores the body part in the recipient's file
system it can convert the internal file references (tokens) into
valid local references.

2.4 Processors for Non-SGML Data

Non-SGML data requires the SGML parser to invoke a processor to
format the data.  The correspondence between the file name and the
application is contained in the type field of the SGML entity
declaration  and the SGML notation declaration  for that type.
The notation declaration  contains the operating system command
string to invoke or launch the processor.  That is, the string in
the notation declaration  is an arbitrary  command.  There are two
problems with this situation, the command may only be valid in the
sender's environment  and, if it is valid in the recipient's ,
invoking that command is a security hazard.

Therefore, this document requires that any type used in an SGML
notation be an valid MIME content type (or an extension token) and
that the unpacker substitute a local string for the string in the
notation declaration.

3    The SGML Subtypes

A complete document may be a single instance in which all the
other document parts are defined by existing standards or private
agreements.  It may also be a set of parts several of which must
be included in the MIME message.  Two SGML subtypes are defined,
content types application and multipart.  Both
body part content types use the same parameters.  The multipart
subtype is considered first, it is the general case.  The
application subtype is a simplification for the case where the
multipart would contain a single part.  It is also used to contain
SGML subdocument entities, that is text with mark-up.

3.1 The Multipart/SGML Subtype

An SGML document carried in a MIME message as a Multipart body of
subtype SGML (Content-Type: Multipart/SGML).  The content-
type parameters specify each of the parts of the SGML document.
Additional parameters specify the software that  created the
document and the applicable SGML standard.

In a complex document  some of the SGML document parts are
references to standard parts  and the others as filenames.  In the
latter case the filename tokens must appear in exactly one Content-
Reference: header in an enclosed body part.  Inside the document
itself, the file names must be replaced by their tokens.

Thus a complete SGML document can appear as the following MIME
message.

    Content-Type: Multipart/SGML; instance=SSBradio;
    dtd=sgml-dtd-mtce-radio; boundary=tiger-lily

     --tiger-lily

    Content-type: Application/SGML
    Content-reference: SSBradio

    <! ... an SGML instance >

    --tiger-lily
    Content-type: Image/gif
    Content-reference: sgml-radio-figure-1

    ...
    --tiger-lily
    Content-type: Application/SGML
    Content-reference: sgml-dtd-mtce-radio

    <! ... a DTD that references the file Figure1>

    --tiger-lily--

3.2 The Application/SGML Subtype

When transferring a file containing text and mark-up within a
Multipart/SGML message or when a complete SGML document can be
contained in a single message the content-type: Application/sgml
can be used.

application-subtype    := ("octet-stream" *stream)
        /    "postscript"
        /    ("sgml" *sgml-parm)
        /    extension-token


The following example shows a MIME message an document instance
which specifies a dtd.

    Content-Type: application/SGML;
        dtd="//USA-DOD//DTD MIL-M-21742 911991//EN"

    <! ... an SGML instance >

3.3 Character Set Considerations

It is expected that SGML documents will use the ASCII character
set.  For documents not in the US-ASCII character set, the
charset= parameter of the Content-Type: field specifies the actual
character set.  Note that the values of the charset parameter must
be registered with IANA,  or be a mutually agreed upon extension-
token (i.e., charset=X-set).

Values contained in the MIME headers must use be drawn from [US-
ASCII] and conform to[RFC-822].  Where the sender's file names do
not meet this requirement the conventions specified in  [RFC-HDRC]
may be used.

4    The Content-Reference Header Field

The Content-Reference: header field provides the linkage between
file references within the SGML document and the MIME body parts.
It contains the unique file name token which represents the
sender's file name to which the body part corresponds.  The
process that handles the Multipart/Compound-SGML body part will
use this value to convert internal file references into valid
references in the receiver's file system.

The syntax is:

    reference := "Content-Reference" ":" (token / quoted-string)

5    SDIF [ISO-SDIF] Data Streams

[This part need work -- Ed]

SDIF is an interchange format standard for SGML documents [ISO-
SDIF].  It defines a data stream that may contain several SGML
documents.  This section defines a Multipart subtype RSDIFS for an
SDIF data stream that contains one or more Multipart/SGML
documents.  Messages that conform to the SDIF subtype will conform
to [ISO-SDIF].

Briefly an SDIF data stream is a sequence of SGML documents and
their subdocument and external entities (c.f. Appendix A).  These
external entities are defined in the DTD and are referred to via
their SGML name in the document intstance.  The scope of an enitiy
name is the document or subdocument in which it is defined.  Thus
names are not unique across documents and subdocuments.  To
provide unique names within the SDIF data stream, each entity is
assigned a sequential number.  Each SGML document or subdocument
structure in the SDIF stream lists the number of the first entity
it contains.

An SDIF data stream is encoded within a MIME message as a
Multipart/SDIF body part.  It contains one to three body parts.
The first and last body parts are optional.  They are labelled
with a content description field whose value is "related-documents-A"
and "related-documents-B" respectively and are Multipart/Mixed.
These multipart bodies contain only
Multipart/SGML or Application/SGML (mime/sgml is for convenience
where the particular content type does not matter) body parts.
The second body part, of the three Multipart/SDIF body parts, is a
mime/sgml body part.

The Multipart/SDIF content type has a character set parameter
which specifies the character set used for SGML markup tokens
through-out the data stream.

There are five SDIF entity types:

    subdocument    These can contain references to external
            entities as well as marked up text.

    text        An external entity containing only marked
            up text.

    data        An external entity containing non-SGML
            data, images, for example.

    public-text    Corresponds to a PUBLIC external reference
            and contains a NULL message body.  [A
            reminder to readers without intimate
            knowledge of SGML, PUBLIC text can be
            located by SGML processors without further
            identification.]

    cross-reference    Corresponds to a previously included
            external entity.  This avoids duplicating
            material previously included.  It contains
            a NULL message body.  This docment requires, in
            contrast to [ISO-SDIF], that the
            referenced body part have already appeared.
            That requirement enables the user agent to
            display the SGML documents as they are
            encountered.

The subdoucment and text SDIF entities become Application/SGML
body parts and data entities are encapsulated as the appropriate
MIME content type.  The last two entities have null message bodies
and are handled as parameters, public and cross-reference, of an
Application/SDIF content type.  The syntax is:

    application-subtype :=    <existing> / RsdifS sdif-param

    sdif-param    :=    ";" "public" "="
                    <an SGML PUBLIC identifier>
               /    ";" "cross-reference" "="
                    <a previous MIME body part>
    <-- the enclosing Multipart/SDIF body part is
    take as the root (level 1) for numbering body
    parts -->

SDIF requires the entity name to accompany each entity in the data
stream.  When MIME is used to transfer SDIF data streams the
entity name will be the value of the content description field in
each body part.

Since SDIF does not distinguish the parts of a document entity
(declartion,  dtd, and instance) when SGML documents are contained
in a Multipart/SDIF message the document is sent as a single body
part.  The application can apply default values for unspecified declarations
and DTDs.

Finally, SDIF uses sequential numbers to uniquely identify each
entity, an entity-identifier in [ISO-SDIF]  and to locate the
position of the first external entity, a first-identifier, of each
document.  These are not necessary when using the methods in this
document but can be derived.  Within a Multipart/SDIF message number
each body part sequentially, starting at 1 with the first
Application/SGML body part.  Note that the only Multipart body
part that can be present in a Multipart/SDIF message is
Mulitpart/Alternative.  That will resolve into a single body part
and shall be treated as though it were a non-multipart body part.
The subdocument, text and data entities may, in fact, be
Message/External body parts. With the numbering described the
unpacker may, if needed,  build a table to translate body parts into
SDIF entity numbers.

6    Security

An SGML parser can be directed to invoke a local process, usually
to format or display a grpahical image.  That capability presents
an opportunity for abuse.  To understand the potential problems
requires understanding two SGML consturcts, entity and notation
statements, presented below.  Capitalized items are literals,
lowercase ones are tokens, and the special characters are markup
escape squences.

    <!ENTITY name SYSTEM file NDATA type>
    <!NOTATION type SYSTEM qstring>

The document text will refer to name which, in turn, will cause
the application, type, represented by qstring to be invoked.
Qstring could be the DOS command "delete *.*".

To eliminate potential problems it is recommended that the
unpacker replace notation contained within the message with the
appropriate statements for the recipient's environment.  An
implementation may use a local configuration file that identifies
the acceptable types and inform the user of types in the message
that are not available in the local environment.  They could be
replaced by a no-operation NOTATION statement.  It is recommended
that the list of acceptable types be drawn from the MIME set of
types and subtypes.

SGML also provides for sending non-interpreted data to the display
device or typesetter.  The security hazard presented is similar to
those posed by the use of PostScript.  Greater threats may be
posed by more "powerful" display systems and typesetters.
Unautorized access to the recipient's system and resources may be
possible.

7    References

[ISO-SGML]    ISO 8879:1988, Information processing -- Text and
        office systems -- Standard Generalized Markup Language
        (SGML).

[ISO-SDIF]    ISO 9069:1988, Information Processing - SGML Support
        Facilities -- SGML Document Interchange Format (SDIF).

[RFC-822]    Crocker, D., Standard for the Format of ARPA Internet
        Text Messages, August 1982, University of Delaware, RFC
        822.

[RFC-HDRC]    Moore, Keith, Representation of Non-Ascii Text in
        Internet Message Headers,  June, 1992, RFC 1522

[RFC-MIME]    Borenstein, N. and Freed, N., MIME (Mulitpurpose
        Internet Mail Extensions): Mechanisms for Specifying
        and Describing the Format of Internet Message Bodies,
        June 1992, RFC 1521.

[US-ASCII]    Coded Character Set -- 7-Bit American Standard Code for
        Information Interchange, ANSI X3.4-1986.

8    Acknowledgements

The author acknowledges Andy Gelsey, Accurate Information Systems,
Inc., Nathaniel Borenstein, Bellcore, Einar Stefferud, Network
Management Asscoiates, Inc, John Klensin, MIT, and Erik Naggum,
for their suggestions, explanations, and encouragement.  No errors
or faults in this document can be ascribed to them, they all
belong to me.

UNIX is a registered trademark of UNIX System Laboratories, Inc.

9    Author's Address

Ed Levinson
[e-mail]
Accurate Information Systems, Inc.
2 Industrial Way
Eatontown, NJ  0772

Appendix A.   SGML for IETFers

This appendix describes of the elements of the Standard
Generalized Markup Language (SGML) that are key to understanding
the relationship between SGML and the Multipurpose Internet Mail
Extensions (MIME).  For the purposes of this discussion, and
without doing too much damage to the SGML specification, an SGML
document contains text, markup, and references to non-text
document elements (e.g., graphics).  For a complete and accurate
description see ISO 8879, Information Processing - Text and office
systems - Standard Generalized Markup Language (SGML).

An SGML document has the following structure (the parenthesized
numbers refer to productions in ISO 8879) and is processed by an
application called an SGML parser.  Note that Internet style ABNF
is used for notation here, [ISO-SGML] uses a different style.

sgml-doc    ::=    sgml-decl dtd doc-inst    (2)
sgml-sub-doc    ::=    dtd doc-inst        (3)

Sgml-decl defines the various elements and parameters of SGML.
    For example, the characters that introduce and end
    markup tags, R<R and R>S respectively will be used
    here, the maximum length of markup tags, etc..

Dtd    is a document type definition (DTD) which defines the
    structure of the document, most important for interchange
    considerations the DTD contains references to external
    files, system commands, and text to be sent directly to a
    typesetter or printer.

Doc-inst is the actual document text; it includes graphic
    elements, other text with or without markup, by reference
    to DTD elements.

The remainder of this discussion focuses on two elements which a
DTD uses to reference other things, entities and notations. They
appear in the DTD and have the following format.

entity    ::=    "<!" "ENTITY" name e-text ">"    (101)
e-text    ::=    q-string | data | b-text | external    (105)
data    ::=    ( "CDATA" | "SDATA" | "PI" ) q-string    (106)
external    ::=    ext-id ( "SUBDOC" | ( "NDATA" type ))    (108)
ext-id    ::=    ( "SYSTEM"  q-string)  | ( "PUBLIC" pub-id [q- string] )(73)
notation    ::=    "<!" "NOTATION" type ext-id ">"    (148)

where name is a character sting, and the definition of b-text left
to ISO 8879; for convenience q-string has been substituted for the
SGML term parameter literal.  Entities referred to via the SUBDOC
keyword differ from SGML documents in that they cannot contain an
sgml-decl.

Using the above productions the following sample entities
demonstrate the important issues. Name, xname, and type are alphanumeric
tokens and q-string is a series of characters enclosed in double
(or single) quote marks.

<!ENTITY name PUBLIC pname>    (A)
<!ENTITY name SYSTEM fname>    (B)
<!ENTITY name SYSTEM fname NDATA type>    (C)
<!NOTATION type SYSTEM command>    (D)
<!ENTITY name PI q-string>    (E)

Form A refers to a well known or "public" name that the SGML
parser is able to resolve; in the marked up text there will be a
markup item "&name" that directs the parser to include the
corresponding public file.  Similarly, form B corresponds to a
locally known file.  Form C allows the markup text to refer to non-
SGML data, an image for example, and the type parameter must match
the type of a NOTATION element .  The matching element's command
parameter specifies the command which processes the file fname.
Finally form E, processing instructions, specifies a string of
characters to be sent directly to the output device.

These examples give rise to the following issues when the document
is transferred from one environment to another.

A    Is the public name known to the recipient?  The recipient SGML
    parser may not know of the public file and this will be
    discovered when it processes the document.

B    What is the file name on the recipient system?  There must be
    some process which binds the sender's file names to the
    recipient.

C    See B and D.

D    Direct use of the NOTATION form is a large security risk, an
    invitation to a Trojan Horse attack.  The recipient must be
    protected from a sender invoking an arbitrary command on the
    recipient system.

E    Processing instructions permit the sender to manipulate the
    recipient output device.  This is the same risk that exists for
    PostScript documents and is not addressed.

Appendix B.  Content-Type registrations
_________________________________

B.1 The Application/SGML Content-Type

(1)    MIME type name: Application

(2)    MIME subtype name: SGML

(3)    Required parameters: none

(4)    Optional parameters: declaration, dtd, instance, fosi, charset

(5)    Encoding considerations: may be encoded

(6)    Security considerations: see RFC section 6

(7)    Specification:

This subtype is used for text marked with the Standard Generalized
Markup Language.  Body parts of this subtype will contain a
Content-Reference: field if this body part is referred to as a
file by an SGML document or subdocument entity or if it is
explictily referred to in a Multipart/SGML parameter.
_________________________________

B.2. The Application/SDIF Content-Type

(1)    Mime type name: Application

(2)    MIME subtype name: SDIF

(3)    Required parameters: one of public or cross-reference

(4)    Optional parameters: none

(5)    Encoding considerations: none

(6)    Security considerations:

(7)    Specification:

This subtype contains a NULL or empty message body.  The value of
the public parameter is an SGML PUBLIC entity identifier.  The
value of cross-reference is the body part identifier of a
previously occurring body part.
_________________________________

B.3.  The Multipart/SGML Content-Type

(1)    Mime type name: Multipart

(2)    MIME subtype name: SGML

(3)    Required parameters: boundary

(4)    Optional parameters: declaration, dtd, fosi, instance

(5)    Encoding considerations: none

(6)    Security considerations: see RFC section 6

(7)    Specification:
_________________________________

B.4.  The Multipart/SDIF Content-Type

(1)    Mime type name: Multipart

(2)    MIME subtype name: SDIF

(3)    Required parameters: boundary

(4)    Optional parameters: charset

(5)    Encoding considerations: none

(6)    Security considerations: none